
<?php
 include "counter.php";
pagestart();
?>
<html>
<?php pagehead("Password handling design");
?>
<body bgcolor="white">
<?php pagetop("Password handling design") ?>

<h2>Goals for password redesign</h2>

<ul>
<li>Make the users' password in the database encrypted, so that it
can't be compromised by attacks on the counter
<li>Make the users' password changeable by the user
<li>Lesser goal: Be consistent that users log in by email address
<li>Accepted damage: We can't remind people of their passwords
<li>Consequence: We need a password reset mechanism
</ul>

<h2>Old design for passwords</h2>
The current code uses the word "key" for passwords, they're stored in
the user record in the "key" field, are numeric, and consist of the
user number + a dash + a random number.
<p>
The login code allows people to specify only the part after the dash,
but the emailed password reminders send out the whole thing.

<h2>New design for passwords</h2>
A new field, "password", is added to the users database. This should
be a standard salted MD5 hash of the user password (if we can find the
right library routine to create that). (MD5 is heavily hurt by recent
cryptographic advances, so HMAC-SHA256 would be a better algorithm,
but I don't think that's in standard libraries yet. In any case, the
field should contain flags so that one can have multiple algorithms.)
<p>
The email reminders, instead of a password, give an URL for the login
page (no password), and an URL that can be used for a secure password
reset (timestamped, salted hash of hashed password).
<p>
A secure password reset consists of the user clicking on an URL he got
in the mail, and filling in his new password. ("secure" should really
be in quotes here - it's no more secure than the user's email). After
a password reset, the user is logged in.

<h2>Transition to the new scheme</h2>

First, write the code, of course.
<p>
The existing password database (key field) can be converted, since
it's cleartext. The conversion should only take the last part of the
password (the random number); the calling code should strip off the
userID if it is supplied. (Small danger: someone who sets their
password to the userid+somethingelse will be in trouble)
<p>
At Flag Day, the password check routine starts looking at the new field.
<p>
The password change form should be opened up after the conversion is
complete; otherwise, the two fields risk becoming desynchronized.
<p>
The change from userid to email as login name is mainly cosmetic,
since both are allowed now; the main change is the prompt, and that
"you are logged in as" should display the main email address, not the
user number. This can be done indepedently from other efforts.


<?php pagebottom() ?>
</body>
</html>
